REMARKS 



This Amendment is in response to the Final Office Action dated April 12, 2010. Applicant 
respectfully requests reconsideration and allowance of all pending claims in view of the above- 
amendments and the following remarks. 

I. CLAIM REJECTIONS UNDER 35 U.S.C. §1 12 - CLAIM 23 

A. "The Terminal" 

Claim 23 was rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite with respect to 
"the terminal". 

Accordingly, Applicant has amended claim 23 to provide proper antecedent basis for the 
terminal. 

Applicant respectfully requests that the proposed amendment be entered after the final rejection 
since this amendment is made for formality reasons only and raises no new issues. 

B. Claim 23 is Fully Supported By the Written Description 

Claim 23 was rejected under 35 U.S.C. 112, first paragraph, as allegedly failing to comply with 
the written description requirement. Specifically, the Office Action states that the specification 
fails to support, 

"a dependency unit and said dependency unit being an access unit." 

1. " Dependency Unit " 

As Applicant described in its prior response, claim 23 is fully supported by the original 
specification. 

For example the first paragraph on page 1 of the specification states: 

More specifically, the invention relates to the optimisation of the processing of 
these elementary stream units when the latter are dependent from, or related to, 
one or several other stream units . (Emphasis added). 

Any person of ordinary skill in the art would understand that the above sentence clearly supports 
the notion of a "dependency unit", since the sentence clearly describes that some of the 
elementary stream units depend from other stream units. 
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Further, the term "dependency" is used throughout the entire specification . For example, page 
17, line 13-16 states, 

The stream will indicate for each of these Access Units a dependency with respect 
to a stream on which it depends . 

Further, page 17, lines 16-23 describes, 

This principle is illustrated by Figure 1 . The stream unit 1 1 of a dependent stream 
10 normally includes a header (SLHeader) 111 and a data field (SL payload) 1 12. 
The header 111 includes, in particular, two pointers, Depl and Dep2, which 
define the dependency links 12 and 13 with stream units 141 and 142 , 
respectively, of a base stream 14, which must be known in order to process the 
stream unit 1 1 . (Emphasis added). 

Indeed, 

on page 25 of the application as filed (the first lines of the appendix), a stream unit is 
defined as being an access unit (see also, page 16, line 29 to page 18, line 22, for 
example); 

the "designates" term is utilized in claim 12. 

More specifically, on page 25 of the patent application as filed, a definition of the stream unit is 
given: 

Stream Unit (AU: Access Unit) 

A data unit that is accessible individually in an elementary stream. A stream unit 
(or access unit) is the smallest entity to which a time data element can be 
attributed. 

This clearly demonstrates that along the specification, and the claims, the "stream unit" is in fact 
an "access unit". This is also described on page 17, lines 5 and 14. 

Moreover, the "dependency" term is used all along the specification. 

n. CLAIM REJECTIONS - 35 USC § 103 

Claims 18-20 were rejected under 35 U.S.C. 103(a) as being allegedly unpatentable over Pierre, 
U.S. Patent No. 7,000,245 in view of Putzolu, U.S. Patent No. 6,205,140 and Furukawa, U.S. 
Publication No. 2002/0071434. 

Claims 1-15, 17, 21 and 22 were rejected under 35 U.S.C. 103(a) as being allegedly unpatentable 
over Pierre, U.S. Patent No. 7,000,245 in view of Putzolu, U.S. Patent No. 6,205,140 and 
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Furukawa, U.S. Publication No. 2002/0071434 as applied to claims 18-20 above, and further in 
view of Okura, U.S. Publication No. 2001/0027468. 

A. Short Summary of Arguments 

An "access unit" has a real technical meaning as described in the MPEG-4 System 
standard. So it cannot be interpreted "broadly". 

Access units are not physical data packets (like in the RTP protocol). So "access unit" 
and "data packet" are not the same thing in an analysis under 35 U.S.C. § 102(b). 

The Examiner believes that the document "Putzolu" comprises an incentive to be 
combined with the document "Pierre". This is not true. If the two documents were 
combined, the skilled person in the art would only obtain a system in which the streams 
would be synchronised "globally", and not "access unit" by "access unit". 

Furthermore, the Examiner mischaracterizes Putzolu in an attempt to make the 
rejection: when explaining an alleged motivation to combine, the Examiner replaces the 
term "component" used by Putzolu by the term "data packets", which have clearly 
different meanings. Applicant believes that the Examiner improperly considers that 
stream units and streams are the same thing (because it is convenient for his 
demonstration under 35 U.S.C. §103). 

B. File Situation 

The present disclosure relates to data transmission in the form of data stream(s), each 
made up of elementary stream units (or packets). An exemplary aim of the disclosure is to 
optimize processing of these stream units when they are dependent of preceding stream 
units in the same stream, or in another stream. 

In known techniques, an important difficulty is that of synchronization, when the 
transmission is made in an asynchronous way. In this case indeed, some stream units 
emitted after can be received before previously emitted ones. In such a case, one cannot 
process a received unit of stream, if it is dependent on a preceding unit of the stream not 
yet received. 

An aspect of the present disclosure proposes a new and inventive approach, by 
synchronizing the access units . The streams themselves are not synchronized. The 
synchronization of the streams themselves is realized, for example, by the "Object 
Descriptor" of a stream which is dedicated to the description of the scene. 
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C. Position of the Examiner 

In this sixth official action, the position of the Examiner has not changed. Indeed, the 
Examiner believes that the arguments previously presented in response to the previous 
official notification are not persuasive. 

More specifically, the Examiner believes that the term "access unit" is a broad term that is 
not defined in the claim. In other words, the Examiner believes that the "access unit" has no 
particular technical meaning and should be interpreted broadly (as for example a single data 
packet). 

The Examiner also believes that the document "Putzolu" comprises an incentive to be 
combined with the document "Pierre" who was recently cited by the Examiner in the 
preparation of the fifth official notification. 

The Examiner considers that the sentence from Putzolu, col. 1, lines 55-61, "It would 
therefore be advantageous to provide a method of communication (or association) to 
dynamically describe the relationships (or dependencies) among the components 
comprising a media presentation, thereby allowing the composition of a media presentation 
to be varied in response to information that becomes available as the presentation 
progresses" is a motivation to combine the "Pierre" and "Putzolu" documents. 

D. Position of the Applicant 

1. The Applicant does not agree with the Examiner. 

Indeed, the Applicant thinks that the term "access unit" is not a broad term. More 
particularly, the term "access unit" is restrictively defined in the « MPEG4 system » 
standard (Glossary and Acronyms): 

"Access Unit (AU): A logical sub-structure of an Elementary Stream to facilitate 
random access or bitstream manipulation. All consecutive data that refer to the 
same decoding time form a single Access Unit. " 

Thus: 

a. the term "access unit" has a precise technical meaning , known to the 
skilled in the art, and it is therefore not possible to interpret it broadly ; 



b. the "access unit" is a sub-logical structure, it cannot be considered, 
functionally, to a physical structure, such as an example RTP packet or file 
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(as described in 'Bob', column 8, line 20-38, which clarifies that the data 
objects are files). 

This means that an "access unit" is not a packet like a RTP packet. 
2 The Examiner Fails To Establish a Prima Facie Case of Obviousness 

The Examiner bears the initial burden of factually supporting any prima facie conclusion 
of obviousness. 1 If the Examiner does not produce a prima facie case, the applicant is 
under no obligation to submit evidence of non-obviousness. 2 

To establish a prima facie case of obviousness, three basic criteria must be met. First, 
there must be some suggestion or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art, to modify the reference 
or to combine reference teachings. Second, there must be a reasonable expectation of 
success. Finally, the prior art reference (or references when combined) must teach or 
suggest all claim limitations. The teaching or suggestion to make the claimed 
combination and the reasonable expectation of success must both be found in the prior 
art, and not based on applicant's disclosure. 3 

Applicant respectfully traverses the § 103 rejection because the office action has not 
established a prima facie case of obviousness. 

a. The cited prior art does not teach or suggest all the claim limitations. 

The cited prior art does not disclose all of the elements and limitations of claim 1. 

Indeed, data objects of "Pierre" are not equivalent to access units of the patent 
application. Specifically, the Applicant will demonstrate that "access units" cannot be 
considered as data objects. 

In fact, in column 8, lines 20 to 38, 'Pierre' discloses what the data objects are. In 
particular, 'Pierre' indicates that data objects are stored as files on a storage medium of 
mass and / or used directly (column 6). 

Data objects are part of a program (column 4, lines 50 to 62) and are transmitted 
cyclically (column 4, lines 63 to 66) as part of the Carousel (The Carousel is described in 
column 1, line 31 to 47). 



1 MPEP Sec. 2142 
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Therefore, the data objects of 'Pierre' cannot be considered "access units", nor can the 
"access units" of the present claim s be regarded as a kind of 'superset' of the data objects 
of 'Pierre'. 

In fact, in the present claims, an "access unit" does not contain a sound or a picture in its 
entirety as described in 'Pierre' . 

The interpretation that is made by the Examiner does not therefore seem appropriate on 
this first point. So, in fact, 'Pierre' does not meet all the limitations of the claim except 
"wherein said pointer is a dependency pointer. . ." as alleged by the Examiner in the last 
paragraph of page 6 of the Office action. 

Indeed, as "Pierre" does not explicitly disclose that a "data object" is an "access unit", 
'Pierre' does not meet the limitation "each of said stream or streams being made of 
access unit" . 



Furthermore, the access units as claimed are not transmitted cyclically as part of a 
Carousel. 

b. The Office Action has not provided a valid sueeestion or motivation to 
combine the cited references. 

Although evidence of a motivation to combine need not be found in the prior art reference 
themselves, if it is found in the knowledge of one of ordinaiy skill in the art or, in some 
cases, from the nature of the problem to be solved, the Office Action must do more than 
simply discuss the ways that the multiple prior art references can be combined to read on 
the claimed invention. Rather, the Office Action must point out "specific information in 
[the two references] that suggests the combination." "The Board [must] explain what 
specific understanding or technological principle within the knowledge of one of ordinary 
skill in the art would have suggested the combination". 

In KSR Int'l Co. v. Teleflex Inc. et.al. 6 , the Court re-affirmed that: 

"Rejections on obviousness grounds cannot be sustained by mere conclusory statements; 
instead, there must be some articulated reasoning with some rational underpinning to 
support the legal conclusion of obviousness". 7 



4 See Dystar Textilfarben GmbH & Co. Deutschland KG v. C.H. Patrick Co. , 464 F. 3d 1 356, 1 366, 80 USPQ2d 

5 Id. at 1367 (citing in re Rouffet, 149 F.3d 1350, 1357 (Fed. Cir. 1998) 

6 KSR Int'l v. Teleflex, Inc., 127 S.Ct. 1727.82 USPQ2d 1385 (2007) 

1 Id 
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Although common sense directs one to look with care at a patent application 
that claims as innovation the combination of two known devices according 
to their established functions, it can be important to identify a reason that 
would have prompted a person of ordinary skill in the relevant field to 
combine the elements in the way the claimed new invention does. 8 

Furthermore, even if the one of ordinary skill in the art would have combined 'Pierre' and 
'Putzolu', he wouldn't have obtained the limitations of claim 1 as argued in the Office 
Action. Indeed, the disclosure of 'Putzolu' is based on RTP protocol (see col.3, line 33). 
This protocol is well known from the one skilled in the art and is using a PDU sequence 
number for reordering the packets. 

i. Streams vs Stream Units/Access Units 

Even if 'Putzolu' discloses in Fig. 2 (col. 5, lines 1-4, 28-33, 38-44) that the dependency 
information included in the descriptor defines a list of media streams ( not stream units or 
access units ) needed for delivering the given media stream, the Examiner has not 
demonstrated why it would have been obvious to one of the ordinary skill in the art at the 
time of the invention to modify Pierre's system by using descriptor of a stream unit for 
pointer of Putzolu. 

Indeed such a modification is not obvious. 'Pierre' discloses data objects which contain 
pictures, sound etc. Thus, the Data Objects of 'Pierre' are not packets or units. As the 
Examiner describes it, in 'Putzolu', the dependencies between streams (and not stream 
units ) are described via 'data packets'. 

ii. The Examiner Mischaracterizes Putzolu by Replacing Terms 

Convenient for the Examiner' s Conclusions 

The Examiner considers that the sentence, "It would therefore be advantageous to 
provide a method of communication (or association) to dynamically describe the 
relationships (or dependencies) among the components comprising a media presentation, 
thereby allowing the composition of a media presentation to be varied in response to 
information that becomes available as the presentation progresses" provides a 
motivation to combine documents "Pierre" and "Putzolu". (citing Putzolu, col. 1, lines 
55-61). 

The Applicant respectfully disagrees. This sentence indicates that a solution is desired for 
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providing a method for dynamically describing the relationships (or dependencies) among 
the components comprising a media presentation. 

There is no mention of "data packets" in the sentence of "Putzolu" (but only of 
component). Thus the Examiner has not brought the evidence that there is a 
motivation for combining the two documents "Pierre" and "Putzolu", because the 
Examiner has modified the "alleged" motivation by using wording from the other 
document. 

Thus, such a modification to the wording of Putzolu, by replacing the term 
"component" by "data packet", is clearly evidence that the Examiner needs more 
technical features for justifying the motivation to combine. 



iii. Combination Would Still Fail to Achieve the Claimed invention 

If the one of ordinary skill in the art would have wanted to modify 'Pierre', to describe 
dependencies among the data packets so the arrangement of a media presentation to be 
varied in response to information that becomes available as the presentation progresses 
('Putzolu', coll, lines 55-60) then he wouldn't have obtained the limitation expected by 
the Examiner. 

The one of ordinary skill in the art would rather have obtained a system in which the data 
objects of 'Pierre' would have to be 'cut/divided' in a set of RTP packets, such as taught 
by 'Putzolu'. Indeed, 'Putzolu' discloses that the stream is divided into RTP packets (not 
any packet of any protocol). Thus the streams of 'Pierre' would have been cut into RTP 
packet, where, as described in col.5, lines 1-4, 28-33, 38-44 of 'Putzolu', the dependency 
information included in the RAP descriptor (not any descriptor) defines a list of media 
streams needed for delivering the given media stream. 

The proposed modification would not have dependencies on stream units (or access 
units) . 

Finally, despite the above results, even if the one of ordinary skill in the art continues 
modifying its previous system in view of Furukawa, he would not have obtained all the 
limitations and features of the claims. 

Indeed, the pointer which is featured on paragraph §0063 of Furukawa is not a pointer, 
as such, or as recited in Applicant's claims. Furthermore, Furukawa uses the term 
'urgent pointer'. So the one skilled in the art would have asked 'what is an urgent 
pointer?' 
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Referring to the standard defining the header package 'TCP' (RFC793), we have a 
definition of this field 'urgent pointer': 

TCP also provides a means to communicate to the receiver of data that at some 
point further along in the data stream than the receiver is currently reading there 
is urgent data. TCP does not attempt to define what the user specifically does 
upon being notified of pending urgent data, but the general notion is that the 
receiving process will take action to process the urgent data quickly. 

Read more: http://www.faqs.Org/rfcs/rfc793.html#ixzzOZqg20ZSF 



Thus, the one of ordinary skill in the art would have obtained a system in which the TCP 
packets (not the RTP ones of 'Putzolu' and furthermore not the 'data objects' of 'Pierre' 
would have an urgent pointer, for which, as told in the RFC793, there is no "attempt to 
define what the user specifically does upon being notified of pending urgent data". 

Even further, such an "urgent pointer" is not a pointer that, "points to at least one other 
access unit of said stream or of another stream that may have been received previously in 
the terminal," as recited in Applicant's claim 1. 

It is important to note that neither Putzolu nor Furukawa discloses a pointer to another 
stream unit (or access unit). So if the Examiner is relying on Furukawa to disclose a 
pointer that is distinct from a sequence number, that pointer would not point to another 
stream unit (or access unit), as recited in Applicant's claims. Rather, it would constitute an 
'urgent pointer' as defined above. 

Thus, the proposed combination of Furukawa' s "urgent pointer" would not satisfy the 
elements of Applicant's claims and is therefore not relevant either separately or in 
combination with the other references. 

c. Conclusion: 

The Applicant has demonstrated that the combination of documents proposed by the 
Examiner does not lead to the invention as claimed in claim 1 (or in the other independent 
claims for similar reasons). 

In Summary, 

"Pierre" is not relevant toward amended claim 1 and depending claims of discussed 
patent application because the data objects described in "Pierre" are not equal nor 
equivalent to the streams unit (or the access units) recited in Applicant's claims. 
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"Pierre", in view of "Putzolu", is not relevant toward amended claim 1 and the 
dependent claims because in order to obtain the invention recited in these claims, it is 
necessary to: 

Detect the approach of "Pierre"was not adequate; 

Understand that it is desirable to take into account the distinct streams, in order to 
simplify the processing of decoding; 

Decide to insert pointers in the stream units themselves to allow synchronising 
stream units with other stream units of another stream previously received . 

This is neither described nor disclosed in "Putzolu" nor in Furukawa. 

For the above reasons, Applicant respectfully requests the allowance of all claims and the 
issuance of a Notice of Allowance. 



The Director is authorized to charge any fee deficiency required by this paper or credit any 
overpayment to Deposit Account No. 23-1 123. 
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